kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.20000824-20010305/[e-mail] _Thu Dec 28 19:12:35 2000.msg

Internet Message Format | 2001-03-05 | 5KB

Return-Path: <[e-mail]>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
    by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA15203
    for <[e-mail]>; Thu, 28 Dec 2000 19:12:34 -0500 (EST)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA21274
    for <[e-mail]>; Thu, 28 Dec 2000 19:12:34 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id TAA06508
    for [e-mail]; Thu, 28 Dec 2000 19:03:14 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Joe Doupnik)
Subject: Re: A wish for the FTP-client
Message-ID: <[e-mail]>
Date: 28 Dec 00 16:36:12 MDT
Organization: Utah State University
To: [e-mail]

In article <92gdsu$26u$[e-mail]>, [e-mail] (Frank da Cruz) writes:
> In article <[e-mail]>, Joe Doupnik <[e-mail]> wrote:
> : In article <92g92f$s9j$[e-mail]>,
> : [e-mail] (Frank da Cruz) writes:
> : >    "...
> : >    mktime() normalizes  the supplied tm structure" -- applies timezone
> : >    conversions, etc.  The problem there is, of course, we don't know, and
> : >    have no way to find out, the server's timezone, and even if we knew it,
> : >    what the rules are to convert to our own.  The struct tm is *already* in
> : >    GMT/UTC, and should not be converted to it again.
> : >
> : > Thus the resulting file date won't be what you want.  I think the object
> : > of copying the server's MDTM is so update can work in both directions.  If
> : > we use mktime(), I think the result will have up to 24 hours of randomness
> : > added or subtracted.  Am I missing something?
> :
> :     I face this problem daily, at 0300 during mirroring operations. As
> : Frank notes well, TZ material makes a mess of trying to reproduce UTC stamps
> : from FTP information. What I do, and what works reasonably well, is use what
> : FTP itself reports in a LIST command (parse according to remote server
> : syntax) which is what it thinks the local time/date of the file is. I then
> : make the client side report the same time/date at user level. This makes
> : local and remote systems "appear" to yield identical file listings.
> :
> Given the ability to parse an "ls -l" listing, this approach works great when
> (a) client and server are in the same timezone, or (b) the client knows what
> timezone the server is in and knows how to "pre-unadjust".  But in the
> general case, the client has no clue as to the server's timezone or daylight
> savings rules, and therefore hasn't a prayer of compensating for mktime()'s
> adjustments.  Also, parsing LIST responses is not a general solution since
> the server might not be UNIX, or might be running some kind of "improved"
> ls, or whatever.
>
> In truth, FTP protocol and UNIX APIs leave a lot to be desired, especially
> when the holes coincide.
>
> - Frank
---------
    Which is what I thought I was saying too. FTP is setup to deal with
user level things, which means seeing time/date in local form rather than as
UTC. And it means viewing LIST command output in the format chosen by the
server machine (and that format can be anything). These are all for the eyes
of humans, as is the result of "quote MDTM filename." It's not holes so much
as by design, and designed with good sense to realize that dissimilar o/s'
are horribly mismatched in file system details and TZ material is worse yet.
    Folks do have the impression that file systems can be merged in some
sense so that client and server share the same nuances of what a file is.
Alas, we know that problem is a total mess in the general case. That is why
I mentioned the file export/import RPC business because the nuances are
better preserved and translated in that machine-level work than in user-level
FTP work. Clearly, better does not mean perfect, often very far from perfect.
    So, we come down to asking what is more important: the file contents
and its name (or a close approximation), or that plus all the metadata about
what the file is. Most of us are happy with the first choice, and for that FTP
does work reasonably well (and hence the FTP support in CKermit does fine).
And hopefully we can quietly forget about files which are not simple sequences
of bytes.
    Joe D.